1. Field of the Invention
This invention pertains generally to compile-time error checking. More particularly, the invention is a method for using compile-time function argument checking to validate variables to be substituted into format strings defined in external data files.
2. The Prior Art
In general, routing devices carry out the operation of reliably transferring network messages or packets within a network of coupled devices, or a collection of such networks. A router operating system (ROS) software which is executed by the routing device provides the basic functions for carrying out various router operations. More particularly, a reliable transfer protocol is provided by the ROS for carrying the routing operations. Additionally, a plurality of subsystems are provided in the ROS for carrying out other related routing tasks as is known in the art.
Occasionally during operation, the router may xe2x80x9ccrashxe2x80x9d or otherwise fail to operate. In such case, it is desirable to present to the user of the routing device information in the form of xe2x80x9cerror messagesxe2x80x9d for resolving the problem in the xe2x80x9ccrashedxe2x80x9d router device. Such information may include error codes which may be communicated to a technical support technician. The technician can research the error code and better assist the user in resolving the router problem. In addition to error codes, other information which may be provided to the user includes a message text which identifies the particular component of the hardware and/or the particular subsystem within the ROS which is causing the problem. Other explanatory or debugging data may also be provided as part of this process.
Providing error messages to the user is a task carried out by the ROS software executing in the router device. Prior art error message implementations are divided into two types. The first type provides the error message data (error codes, message text, etc.) within the program source code of the ROS software. The second type provides error message data externally from the program source file of the ROS, normally in an error message text file. There are disadvantages to both arrangements as described below.
In the former case, where error message data is provided within the program source file, updates or changes to the error message data are cumbersome or difficult to perform. Because the error message routines and error message data are combined with other router routines within the same ROS program source file, a programmer of the ROS would have to search the program source code for the location of the message routines and message data to make changes and corrections. Furthermore, if a programmer were working with more than one ROS program source file, such as when a programmer is working on several revisions of an ROS file, the programmer would have to make the same changes in each ROS program source file, making global error message data change cumbersome and time consuming.
The main advantage of including the error message data in the ROS program source file is the ability to perform compile-time type-checking of variable format arguments. To display an error message to a user, a function within the ROS is normally called (printf, for example) which accommodates one or more xe2x80x9cargumentsxe2x80x9d or xe2x80x9cparametersxe2x80x9d associated with the message.
During compilation of the program source file, the compiler provides type-checking of arguments to format specifiers in message-formatting function calls. For example, an illustrative function call may be:
printf (xe2x80x9cAn error of type %d was generated by %sxe2x80x9d, ID, SRC)
In the above example, the call to the function printf includes three arguments, where the first argument is a literal xe2x80x9cformat stringxe2x80x9d having the value xe2x80x9cAn error of type %d was generated by %sxe2x80x9d. This xe2x80x9cformat stringxe2x80x9d argument is xe2x80x9cnon-variablexe2x80x9d in that its value is fixed in the program source file. In general, this argument value is xe2x80x9chard-codedxe2x80x9d and entered into the program source file by the programmer of the program source file. The above format string includes two xe2x80x9cformat specifiersxe2x80x9d (%d and %s), each starting with a xe2x80x9c%xe2x80x9d symbol followed by an argument type specifier. The remaining arguments (ID and SRC) are xe2x80x9cvariablexe2x80x9d. The format specifiers (%d and %s, in this case) in the format string argument dictate the number and type of arguments to follow in the function call. At compile time, the compiler checks to verify that the ID argument is the proper data-type for the xe2x80x9c%dxe2x80x9d format specifier and that the SRC argument is the proper data-type for the xe2x80x9c%sxe2x80x9d format specifier.
Where the data-type for one or more of the arguments is inappropriate for its corresponding format specifier in the format string argument, a compilation error is generated which points out the type-mismatch in the function call. The ROS programmer can then correct the type-mismatch error and recompile the program source file. Such detection of type-mismatch errors is desirable to correct defects in the program source code of the ROS prior to public release of the ROS. If such type-mismatches are not discovered during or prior to compilation, a potential error or malfunction may result during the run-time execution of the ROS of the router.
In the second error message implementation technique, the error message data (error codes, error message text, etc.) is stored in a separate file from the program source file, normally in an xe2x80x9cerror message text filexe2x80x9d. By providing this error message data in an external text file, the message information can be easily accessed and modified by a programmer. Normally, the error message text file organizes the message data in xe2x80x9csectionalxe2x80x9d format wherein each section applies to a certain component or subsystem of the router, and each section may include one or more messages related to that section. Another benefit associated with externally providing the message data is the ability to use the same error message text file with multiple program source code implementations.
In addition, an external message text file greatly simplifies the process of providing error-messages in multiple languages. For example, where IPV4 error messages are provided in an xe2x80x9cIPV4.msgxe2x80x9d file, multiple language support could be provided by creating an xe2x80x9cIPV4.french.msgxe2x80x9d which contains the French translation of the same error messages provided in the xe2x80x9cIPV.msgxe2x80x9d file.
Error message data are provided to the program source file by calling a function in the program source file which retrieves the pertinent error message data, such as:
IP_bad_route_format=get format (IP_bad_route);
During router operation, the above command retrieves the message text associated with a bad route from the error message text file and stores the message into the variable xe2x80x9cIP_bad_route_formatxe2x80x9d. The variable xe2x80x9cIP_bad_route_formatxe2x80x9d contains the functional equivalent value of the xe2x80x9cliteral stringxe2x80x9d argument as in the first error message implementation, but obtains its value at xe2x80x9crun-timexe2x80x9d during router execution. The variable xe2x80x9cIP_bad_route_formatxe2x80x9d is used in conjunction with the output function (printf) to display the error message to the user. For example, the printing call might be:
printf (IP_bad_route_format, ID, SRC)
The error message is then displayed to the user for troubleshooting the problem associated with the present error. However, since the IP_bad_route_format value is defined at run-time, during compilation of the program source file, the value of the IP_bad_route_format variable is unknown. Unlike the first error message implementation where the message text is xe2x80x9chard-codedxe2x80x9d with the output function printf, the content of the message text and thus the format specifiers within the message text provided by the IP_bad_route_format variable is unknown to the compiler. Accordingly, the compiler will not perform type-checking of such function call statements (i.e., the compiler will not check whether the ID and SRC arguments match the data-type specified by the format specifiers in the IP_bad_route_format variable). Because the compiler does not perform type-checking with respect to this second type of error messaging system, the risk of run-time type-mismatches is increased. As noted above, run-time type-mismatches may result in router faults or errors during run-time execution.
Accordingly, there is a need for a compile-time method for type-checking format arguments which utilizes an external message text file. The present invention satisfies these needs, as well as others, and generally overcomes the deficiencies found in the background art.
An object of the invention is to provide a method for compile-time type-checking of format arguments which overcomes the deficiencies of the prior art.
Another object of the invention is to provide a method for compile-time type-checking of format arguments which uses data from an external file.
Another object of the invention is to provide a method for compile-time type-checking, of format arguments which produces a generated source file from an error message text file which is compiled together with a program source file.
Another object of the invention is to provide a method for compile-time type-checking of format arguments which converts data from an error message text file into a generated source file which is suitable for inclusion into a program source file.
Further objects and advantages of the invention will be brought out in the following portions of the specification, wherein the detailed description is for the purpose of fully disclosing the preferred embodiment of the invention without placing limitations thereon.
The present invention is a method for type-checking format arguments during compile time which uses data in an external file. The invention converts data from an external error message text file into a generated source file suitable for xe2x80x9cinclusionxe2x80x9d in a program source file. The invention compiles the program source file together with the generated source file and performs, among other things, type-checking of format arguments contained within the program source file and the generated source file. The method of present invention is implemented by software which is stored on a computer-readable medium, such as computer memory or a CD-ROM, for example.
The error message text file of the present invention typically includes message data which includes error codes, message text, and other relevant data for debugging errors as is known in the art. This data contained within the error message text file is external to data contained within the program source file, which contains operating instructions for the router, and is the subject of compilation. In the present invention the program source file is typically compiled into a router operating system (ROS) library file, which may be included as part of the router operating system software.
Normally the error message text file divides message data into one or more sections, where each section pertains to a system or hardware function within a router device. Each section related to a system or hardware function may be further subdivided into one or more xe2x80x9cmessagexe2x80x9d subsections, where each subsection relates to a particular error that may be associated with the particular system or hardware function. Each of the xe2x80x9cmessagexe2x80x9d subsections will contain the detailed code, message text, and other data related to a particular problem within the router. While the data within the error message text file is described herein using section and subsection divisions, other methods for storing data within an external file as is known in the art may be used without departing from the scope of the present invention.
The invention converts the error message text file into a xe2x80x9cgenerated sourcexe2x80x9d file, which is included into the program source file as described further below. In general, the invention generates a function definition in the generated source file for each xe2x80x9cmessagexe2x80x9d subsection contained within the error message text file. Each such function definition will be defined with a calling sequence that requires the caller (in the program source file) to pass the correct number and type of arguments to match any format specifier(s) in the corresponding error message text file. For example, an illustrative function definition generated by the invention may be:
Void ROS_error_IP_bad_route (int ID, char*SRC)
{
. . .
printf (IP_bad_route_format, ID, SRC)
. . .
The above sample generated function includes a call to the output function (i.e., printf (IP_bad_route_format, ID, SRC)). Since the first (format string) argument (IP_bad_route_format) is a variable rather than a literal text string, the compiler cannot check the arguments (ID and SRC) against the format of the first argument (IP_bad_route_format).
However, the pre-processing step that generating the function determined that the format string requires one Integer argument and one character string pointer argument and generated the function ROS_error_IP_bad_route to require those arguments. Thus, any program source file that calls ROS_error_IP_bad_route must provide two arguments of these two exact types, or a compile error will occur.
The generated source file is included into the program source file using a xe2x80x9c% includexe2x80x9d command contained in the program source file or other like include command known in the art. For example, a generated source file named xe2x80x9cerrors_gen.hxe2x80x9d would be included into a program source file with the following command:
%include erorrs_gen.h
Normally, the above step of including the generated source file is carried out manually by a programmer inserting the xe2x80x9cincludexe2x80x9d command into the program source file. The invention then compiles the program source file, which in a presently illustrative example is a router operating system (ROS) source file.
During compilation of the program source file, the compiler checks the program source file for errors. Additionally, the compiler checks the included generated source file (errors_gen.h, for example) for errors.